Computer Networks
Computer networks connect a number of computing devices together and transmit data between computing devices. Generally, computing devices in a network may be categorized as servers and clients. Servers provide services to other devices, which may be referred to as clients. The same computing device may function as both a server and a client. A server may provide one or more services on the Internet. For example, a server device might have software running on it that allows it to act as a Web server, an e-mail server, and/or an FTP server. Client devices send requests to servers for particular services offered by the server. For example, a client may run web browser software that directs a request for a website to web server software running on the server device. The web server will process the request and return the requested website to the client.
The mechanisms of how such requests and responses are sent over the computer network is complex. Those of skill in the art use a conceptual model that breaks these functions into layers to help explain the complex interactions that occur when data is transmitted through a computer network. This layered model is sometimes referred to as the TCP/IP stack.
In the lowest layer, the network access layer, data is divided into packets of information that are transmitted as a signal across a physical medium connecting two devices. This layer is hardware-agnostic, meaning that the specific characteristics of the hardware implementations (e.g., a network interface controller (NIC)) are abstracted away by underlying device drivers. More specifically, a device driver provides standardized features and routines which may be used by other software layers without specific knowledge of the underlying hardware implementation. At the network access layer, information is received from the next highest abstraction layer, the internet layer, encapsulated (e.g., by wrapping the received information with control information) to form of one or more packets containing payload segments, and transmitted to a remote device across the physical connection medium.
The internet layer enables communication between devices across multiple networks using addressing and routing. At the internet layer, a device receives an internet protocol (IP) address which is hierarchical and enables another device to route data within the hierarchy accordingly. The IP address of a recipient device may be used by devices within the computer network to forward packets between devices along a path between the source and recipient devices. The internet layer encapsulates data from the next highest abstraction layer, the transport layer, which is then further encapsulated and transmitted by the link layer.
At the transport layer (e.g., TCP, UDP, etc.), data from the next highest layer, the application layer, is encapsulated. The transport layer provides a variety of high-level features, including segmentation, congestion control, and application addressing by way of port numbers. Data may be segmented such that one stream of information is divided into multiple parts for transmission across the network via the internet and link layers. Upon being received by the destination device, the data may then be recombined at the transport layer on the destination device. Port numbers are associated with data transmissions in order to classify data streams. This ensures that a communication may be specifically directed to the correct application or service on a computing device.
At the application layer, applications and services may listen for incoming communications on a specific port number (e.g., port 80 for HTTP requests, port 21 for FTP requests, etc.). Additionally, applications may open ports on a source computing device in order to transmit a request to a destination device. For example, a client device may open port 12211 in order to communicate with a web server operating on port 80 on a destination device. The destination device may then respond to port 12211 on the client device when transmitting a response to the request.
Internet of Things
The Internet of Things (“IoT”) allows objects to be sensed and controlled with network infrastructure, such as clients and servers discussed in the preceding section. IoT devices include physical devices, objects, components, and other items that are embedded with electronics, software, sensors, and/or network connectivity to allow them to connect to networks and each other through the Internet of Things.
Web Frameworks
An application framework is a software library that provides a fundamental structure to support the development of applications for a specific environment. An application framework acts as the skeletal support to build an application. The intention of designing application frameworks is to lessen the general issues faced during the development of applications. This is achieved through the use of code that can be shared across different modules of an application.
A web framework is an application framework that is designed to support the development of web applications including web services, web resources and web APIs. Web frameworks are designed to alleviate the overhead associated with common activities performed in web development. For example, many web frameworks provide libraries for database access, templating frameworks and session management, and development of dynamic websites.
With conventional web frameworks (e.g., Asp.Net, Node.JS, PHP), each framework had to be able to integrate with every kind of web server (e.g., IIS, Apache, Nginx). These conventional frameworks will be referred to as “server-dependent frameworks.” This was done by writing code specific to the APIs for “modules” exposed by each kind of web server. The modules extended the server application's ability to interpret and process computer languages.
For example, a particular webserver might have been capable of interpreting only HTML files. If a website developer wished to use a different computer language for the underlying code for the website under development, a module would have had to be used to enable the webserver to execute and process the other language used for that website (e.g., Ruby, PHP, etc.). As a result, web frameworks had to provide modules for a variety of server applications, each of which had to be tailored to the specific module application programming interface (API) provided by the developers of each of the specific server applications. Further, when operating in this configuration, when a webserver application that understood only HTML received a request for website written in PHP, it would have had to load the associated PHP module and provide the request to the PHP module. The PHP module would then have had to process the request and provide a response to the server application, after which the server application would transmit the response to the requestor.
The conventional server-dependent model had a number of problems. It required framework developers to create customized modules to ensure that the framework could be interpreted by the wide array of available server applications. Further, module APIs provided by a server application could vary depending on the version of the application, which required different versions of each module, thereby introducing yet another layer of complexity for both system administrators and framework developers.
A server-independent framework model was thus developed to minimize this tight integration between the frameworks and the web servers. In this model, the frameworks do not talk directly to the web server, but rather talk directly only to the sockets layer (e.g., WinSock on Windows) that implemented a rudimentary web server (e.g., a mini server or simplified server) that supports a minimal subset of HTTP/1.1. In this way, the framework was not tied to a particular kind of webserver, but could be used with multiple types of web servers. However, while this server-independent model gave the benefit of a framework independence from web-server type, it came at an enormous performance cost. That is, while the simplified server did not require customization for specific server applications, there was a large amount of overhead that resulted from the server application effectively repackaging received requests and responses as it relayed data between the requestor and the simplified server. In some cases, the time to receive and process a client request was 30 times slower than what was observed with the conventional server-dependent framework.
Further, the simplified server was not as secure as the server application. For example, the simplified server, which is not armored against malicious requests, was accessible by other processes running on the same server machine. As such, one malicious or exploited process could be used to take over more web sites running on the same machine using this mini-server. As a result, the simplified server introduced vulnerabilities within an otherwise secure system.
It is with respect to these and other considerations that examples have been made. Also, although relatively specific problems have been discussed, it should be understood that the examples should not be limited to solving the specific problems identified in the background.